Method and system for data security within independent computer systems and digital networks

ABSTRACT

A system and method for authentication, authorization, and access management based on personally identifiable information and data sets pertaining to individual identity and its attributes within independent computer systems and digital networks.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/031,433, filed on Jul. 10, 2018, which claims priority to U.S.Provisional Patent Application Ser. No. 62/530,755, filed on Jul. 10,2017, and is related to U.S. patent application Ser. No. 15/480,313,filed Apr. 5, 2017, which claims priority to U.S. Provisional PatentApplication Ser. No. 62/318,648, filed on Apr. 5, 2016, and is alsorelated to U.S. Provisional Patent Application Ser. No. 62/595,416,filed on Dec. 6, 2017, and which applications are hereby incorporated byreference in their entireties and for all purposes.

FIELD

The present disclosure relates to data security, and more specifically,but not exclusively, to a system and method for authentication,authorization, and access management based on personally identifiableinformation and data sets pertaining to individual identity and itsattributes within independent computer systems and digital networks.

BACKGROUND

Binary methods of authentication for a service or system—whetherone-factor authentication (1FA) or two-factor authentication (2FA)—canbe less than secure to deliver a high integrity of data assurance anddata provisioning for personal access to sensitive information and/orservices for an individual. Even 2FA is subject misuse, tampering,and/or security compromise—especially when the primary second factor isshort message service (SMS), which can be compromised through thegateway.

Trust should never have a binary state. Trust-based decisions cannot beanswered in a simply yes or no fashion. Rather, trust-based decisionsshould account for an aggregation of every data point that a particularparty has access to. A need exists for constant aggregation of everytrust, reputational, and behavioral data point to provide enoughconfidence and assurance for a decision making process.

There are two fundamental challenges. First, aggregating a large volumeof sensitive personal information creates a highly valued hacker target.However, an aggregate of verified personal information can avoidsecurity issues, for example, with incoming data from third partysources. Therefore, better security is needed for aggregated data.Second, legislation—particularly in Europe—is making this task evenharder. The General Data Protection Regulation limits how and what typeof data can be collected, shared, stored, and protected.

Unfortunately, conventional solutions not only fail to capture the fullspectrum of data due to the sensitivity of the personal data, but alsoput personal data at risk by using conventional storage and retrievalmethods. These conventional systems also fail to ensure that suchsensitive data, or insights derived thereof, can be shared, let alone inreal time, as part of decision making. There is currently no way to dealwith the added legal complexity that personal data at large—andpassenger data in particular—is both very sensitive and not able to bestored centrally for privacy legislations. In part, current solutionsstore the data in either a fragmented form or simply offline, therebyfailing to solve the need to effectively use or share that data inreal-time. Overall, this conventional approach fails to comply withregulations and privacy legislation. A need exists to share personaldata without actually sharing the open, underlying information about theperson or a passenger.

In view of the foregoing, a need exists for an improved system for datasecurity management in an effort to overcome the aforementionedobstacles and deficiencies of conventional data security systems

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an exemplary block diagram illustrating one embodiment of adata security management system having a client with a pair ofcryptographic keys.

FIG. 2 is an exemplary block diagram illustrating one embodiment of adata flow for the generation of the pair of cryptographic keys of FIG. 1based on biometric data.

FIG. 3 is an exemplary block diagram illustrating one embodiment of adata flow for encoding the private key of FIG. 1 using biometric data.

FIG. 4 is an exemplary functional block diagram illustrating oneembodiment of control flow between the private key of FIG. 1 and smartcontracts.

FIG. 5 is an exemplary functional block diagram illustrating oneembodiment of a control data flow for changing ownership of ID smartcontract of FIG. 4.

FIG. 6 is an exemplary functional block diagram illustrating oneembodiment of an authentication process using transactions to a randomrecipient addresses using the data security management system of FIG. 1.

FIG. 7 is an exemplary data flow diagram illustrating one embodiment ofa zero-knowledge authentication process that can be used the datasecurity management system of FIG. 1.

FIG. 8 is an exemplary functional block diagram illustrating oneembodiment of an authentication process using transactions to directrecipient addresses using the data security management system of FIG. 1.

FIG. 9 is an exemplary functional block diagram illustrating oneembodiment of a data flow for encoding and storing encoded data usingthe private key of FIG. 1.

FIG. 10 is an exemplary functional block diagram illustrating oneembodiment of a data sharing process between smart contracts usingrandom addresses using the data security management system of FIG. 1.

FIG. 11 is an exemplary functional block diagram illustrating anotherembodiment of the data sharing process of FIG. 10 between smartcontracts using direct addresses.

FIG. 12 is an exemplary functional block diagram illustrating oneembodiment of verification generation process using the data securitymanagement system of FIG. 1.

FIG. 13 is an exemplary top-level block diagram illustrating oneembodiment of verification transaction within the distributed ledgerusing the data security management system of FIG. 1.

FIG. 14 is an exemplary functional block diagram illustrating oneembodiment of a process for one verification transaction generationwithin the distributed ledger using the data security management systemof FIG. 1.

FIG. 15 is an exemplary functional block diagram illustrating oneembodiment of a verification validation using the data securitymanagement system of FIG. 1.

It should be noted that the figures are not drawn to scale and thatelements of similar structures or functions are generally represented bylike reference numerals for illustrative purposes throughout thefigures. It also should be noted that the figures are only intended tofacilitate the description of the preferred embodiments. The figures donot illustrate every aspect of the described embodiments and do notlimit the scope of the present disclosure.

DETAILED DESCRIPTION

Since currently-available data security systems are deficient becausethey are unable to both protect sensitive data by its decentralizationand ensure that this data will have verifiable integrity and consistencyin a decentralized environment without revealing any part of theoriginal, underlying data, a system for data security management canprove desirable and provide a basis for a wide range of data managementapplications, such as managing passenger data that is both verysensitive and not stored (or stored in fragmented form and offline).These goals can be achieved, according to one embodiment disclosedherein, by a data security management system 100 as illustrated inFIG. 1. The data security management system 100 advantageously protectsdecentralized data and ensures that this data will have verifiableintegrity and consistency.

Turning to FIG. 1, the data security management system 100 is shown asincluding a client 201 that generates a cryptographic key paircomprising a public key 202 and a private key 203. The client 201 caninclude any mobile device, personal computing device, mobile telephone,smartphone, tablets, desktop computers, and Internet of Things (IoT)devices. Although shown and described using a single client 201, thedata security management system 100 can support any number of clients201 as desired.

In a preferred embodiment, each client 201 can generate at least onepair of cryptographic keys: the public key 202 and the associatedprivate key 203. The private key 203 is preferably a large cryptographicsecret key. In some embodiments, the data security management system 100can include at least one client-side processor (not shown) configured togenerate these key pairs. In yet another one embodiment, the private key203 can be stored on the client 201 in a special vault (not shown). Inan alternative embodiment, the private key 203 can be stored within theoperating memory (not shown) of the client 201. In some otherembodiments, such as shown on FIG. 2, the pair of cryptographic keys canbe generated from client biometric data, for example, by way ofbiometric feature extraction (e.g., face, fingerprints, voice, retinarecognition, and so on). Because the same biometric features shouldproduce identical cryptographic key pairs, these keys need not be storedanywhere at all. Stated in another way, each time the private key 203and the public key 202 are needed, they can be dynamically generatedusing biometric data from the client 201. The generation of the publickey 202 and the private key 203 is also described in commonly-assigned,co-pending application Ser. No. 15/480,313, entitled “Method and Systemfor Managing Personal Information Within Independent Computer Systemsand Digital Networks,” the disclosure of which is hereby incorporated byreference in its entirety.

In a preferred embodiment, as shown on FIG. 3, the private key 203 canbe locked, protected, and/or encoded using a biometric identification(shown as a biometric key 203) and cryptographic function 232. In someembodiments the cryptographic function 232 includes cryptographicprimitives such as a one-way hash function and/or an encryption functionto produce an encoded private key 231 on the client 201. In someembodiments, the private key 203 can be locked, protected, and/orencoded using a password. In another embodiment, the data securitymanagement system 100 comprises any combination, number, and/or sequenceof private key protection techniques. In yet another one embodiment, theprivate key 203 need not be locked, encoded, and/or protected.

In a preferred embodiment, each generation of new key pairs on theclient 201 is provided with creation of a new associated ledger ID smartcontract 205 in a ledger 207. The ledger ID smart contract 205 includesa computer protocol intended to digital facilitate, verify, or enforcethe negotiation or performance of a contract. The ledger ID smartcontract 205 are trackable and irreversible to enable the performance ofcredible transactions without third parties. Control of the ID smartcontract 205 can be protected using the private key 203. In thisembodiment, one can access and/or control the ID smart contract 205being in possession of only the private key 203. In another embodiment,the ID smart contract 205 can be protected using another private key(not shown), different from the private key 203. The data securitymanagement system 100 is suitable for use with a wide range of ledgers207, such as any immutable distributed ledger, including, for example, apublic Blockchain (e.g., Bitcoin® Blockchain, Ethereum® Blockchain,etc.) and/or a private Blockchain and/or the like. In some embodiments,the ledger 207 comprises a combination of public and/or privateBlockchains. In another embodiment, the data security management system100 comprises a controller smart contract 206 which can be the owner ofthe ledger ID smart contract 205.

As shown on FIG. 4, the private key 203 can lock, protect, and controlaccess to a ledger controller contract 206A. Only having access (e.g.,being in the possession of the private key 203) to the controller smartcontract 206 provides the client 201 with access to, and/or control of,the ID smart contract 205. This advantageously restores control of theID smart contract 205 in the event of client migration to other devicesor the loss of the private key 203 on the client 201. In other words, anew controller smart contract 206 can be generated and ownership of theID smart contract 205 can be reassigned (or added) to a new controllersmart contract 206B, such as shown on FIG. 5. In another embodiment, thedata security management system 100 comprises any number of sequentialsmart contracts, each one in control of the following one, therebyforming a chain of control between each client 201 and ID smart contract205.

In a preferred embodiment, a ledger identifier (e.g., contract id) ofthe ID smart contract 205 is assigned by the ledger 207 and canrepresent a client identifier 237 of a selected client 201 in the datasecurity management system 100, such as shown in FIG. 6. The clientidentifier 237 is preferably a unique value. For example, in an Ethereumcontract, the client identifier 237 can be deterministically computedfrom the address of its creator and the number of transactions thecreator sent at the moment of generation. In other example, the clientidentifier 237 can be a purely random value. In some embodiments, thepublic key 202 of the client 201 can represent the client identifier 237of the selected client 201. In another embodiment, a ledger identifierof the controller smart contract 206 can represent the client identifier237 of the selected client 201. In yet another one embodiment, theclient 201 can manually select their client identifier 237.Alternatively, the client identifier 237 can be assigned externally tothe data security management system 100. In other embodiments, theclient identifier 237 can be derived from the public key 202, the ledgeridentifier of the ID smart contract 205, and/or the ledger identifier ofthe controller smart contract 206 by using a cryptographic function,such as, but not limited to, one-way hashing function (e.g., MDS, SHA-1,SHA-2, etc.).

In a preferred embodiment, an authentication process comprises at leastone authentication response 229 represented by ledger transaction 204made within ledger 207 from ID smart contract 205 and/or controllersmart contract 206 (such as shown in FIG. 6). Only a client 201 is inpossession of the private key 203, meaning that only the client 201 hasaccess to, and is in control of, the ID smart contract 205 and/or thecontroller smart contract 206. Turning to FIG. 6, an example of anauthentication process is shown. As shown, the client 201 can perform aninitial authentication request 235, for example, over Hypertext TransferProtocol (HTTP), HTTP Secure (HTTPS), and/or any other conventional datatransfer protocol, to an authenticator 208. The authenticator 208 cangenerate a random value 236, which can be transferred back to the client201, for example, over HTTP, HTTPS, and/or any other conventional datatransfer protocols.

The authenticator 208, using the client identifier 237 and the randomvalue 236, can produce a cryptographic data 240 using a cryptographicfunction 238. The cryptographic function 238 can include a one-wayhashing function (e.g., MD5, SHA-1, SHA-2, etc.). The authenticator 208produces a ledger request transaction 209 that includes thecryptographic data 240 via an authenticator smart contract 211. Theauthenticator 208 is the owner of the authenticator smart contract 211on the ledger 207. The client 201, having the random value 236 from theauthenticator 208, produces a cryptographic data 239 using thecryptographic function 238. In some embodiments, the private key 203 canbe used with the random value 236 as inputs to the cryptographicfunction 238. Because the client 201 is in possession of the private key203, the client 201 controls the controller smart contract 206, which isthe owner of the ID smart contract 205. Using the private key 203 andthe cryptographic data 239, the client 201 can produce at least oneauthentication response ledger transaction 204 that includes thecryptographic data 239.

In some embodiments, the authentication response ledger transaction 204is a proof and/or verification of possession of the private key 203 bythe client 201 to the authenticator 208 with or without any ledger 207transaction(s). An example of such authentication process is shown inFIG. 7 as a sequence diagram of zero-knowledge authentication. As shown,the client 201 sends a special identity request 222 to the authenticator208. The authenticator 208 responds to the client 201 with a challenge223. By way of example, the challenge 223 can include a random bignumber, such as used by an RSA Factoring Challenge for encryption. Theclient 201 then makes the necessary modifications 224 of this big numberusing the private key 203 and sends the new, modified big number 225back to the authenticator 208. The authenticator 208 checks the modifiedbig number 225 from the client 201 and responds with a result 226 as towhether the challenge-response was correct.

In another embodiment, the authentication process is a modification ofstored data fields within the ID smart contract 205 and/or controllersmart contract 206 data fields requested by the authenticator 208 duringthe authentication process. Although not shown, in some embodiments, theauthentication process of FIG. 7 generates a digital signature by theclient 201 using the private key 203 over data received from theauthenticator 208. In order to authenticate the client 201, theauthenticator 208 validates this digital signature using the public key202. In another embodiment, a zero-knowledge proof of the private key203 knowledge can be generated on the client 201 and be provided to theauthenticator 208 with or without any ledger 207 transaction(s) 204.

Returning to FIG. 6, the authentication response ledger transaction 204can be made to the random recipient address that includes content thatthe authenticator 208 passes to the client 201 (for example, the randomvalue 236 and/or the cryptographic data 239) in order to protect clientand authenticator privacy. In other embodiments, the authenticationresponse ledger transaction 204 can be made to the authenticator 208ledger smart contract 211 directly, such as shown on FIG. 8.

Turning to FIG. 8, an authentication request 228 can be produced by theauthenticator 208 using an authentication request ledger transaction209. In some embodiments, the initial authentication request 228 can beproduced by the client 201. In another embodiment, the initialauthentication request 228, an authentication response 229, and/or awhole or a part of authentication process can be made off of the ledger207 using conventional data transfer protocols (e.g., HTTP, HTTPS,etc.). In some embodiments, the authentication request 228 can be madeusing conventional data transfer protocols and the authenticationresponse 229 can be made as an authentication response to the ledgertransaction 209 within the ledger 207 or vice versa. In otherembodiments, the authentication request 228, the authentication response229, and/or a whole or a part of authentication process can be based ona ledger transaction from smart contracts to smart contracts and/or as aledger transaction from smart contracts to random addresses.

In some embodiments, the initial authentication request ledgertransaction 209 can be made to the random recipient address in order toprotect client and authenticator privacy, such as shown on FIG. 6. Inother embodiments, the initial ledger transaction 209 can be made to theID smart contract 205 and/or the controller smart contract 206 directlyfrom the ledger smart contract 211, such as shown on FIG. 8. However, ina preferred embodiment, the data security management system 100comprises both the authentication request 228 and the authenticationresponse 229 as the ledger transaction 209 and ledger 207 transaction204 accordingly to, on one hand, protect both client 201 andauthenticator 208 privacy and, on another hand, to leave a traceabletrack of the authentication event that has happened. Once authenticationprocess transactions are written onto the ledger 207, it is hard tocounterfeit them or tamper with them. In some embodiments, theauthentication request 228 can be set as a mandatory requirement forauthentication so the client 201 can ensure that the authenticationrequest 228 is generated by the authenticator 208. In some otherembodiments, any number of data transfer sessions using conventionaldata transfers protocols can be performed before, after and in time ofauthentication process in order to share any data and/or metadata neededto perform authentication process between the client 201 and theauthenticator 208. Advantageously, the authentication processesdescribed above rule out the need for use of any kind of passwords.Generally, in order to authenticate the client 201, the possession ofthe private key 203 should be established by the client 201.

In a preferred embodiment, the client 201 can store personal data 210,such as shown in FIG. 9. The personal data 210 can be added by theclient 201, or can be imported from outside of system 100. In someembodiments, the personal data 210 can be encoded (encrypted) and/orprotected using the private key 203 and/or the public key 202 andcryptographic function 233. The cryptographic function 233 can includecryptographic primitives such as a one-way hash function and encryptionfunction to produce encoded (encrypted) personal data 234 shown on FIG.9.

In other embodiments, the personal data 210 can be encoded using anotherkey and/or a password (not shown), different from the private key 203and the public key 202. In another embodiment, personal data 210 can beencoded, ciphered, and/or obfuscated using biometric identification ofthe client 201. In even further embodiments, the personal data 210 canbe encoded and/or obfuscated using any other strong cipher (e.g., AES,etc.) or using a combination of cryptographic techniques. In yet anotherone embodiment, personal data 210 need not be encoded, ciphered, and/orobfuscated at all. In some embodiments, the data security managementsystem 100 does not store any personal data 210 anywhere within system100. Instead, once needed, the personal data 210 can be provided by theclient 201 from outside of the system 100.

In a preferred embodiment, the client 201 can send (share) the personaldata 210 to any other component within the data security managementsystem 100, including, but not limited to, the authenticator 208.Turning now to FIG. 10, the authenticator 208, having the public key 202from the client 201 and a request metadata 243, can produce an encodedrequest 244 using a cryptographic function 242. The cryptographicfunction 242 can include a one-way hashing function (e.g., MD5, SHA-1,SHA-2, etc.). The encoded request 244 to share personal data 210 fromclient 201 to authenticator 208 can be placed by the authenticator 208within a ledger transaction 213.

In some embodiments, the request metadata 243 can represent a pointer onwhich data is needed to be shared from the client 201. In anotherembodiment, the request metadata 243 need not be present. In otherembodiments, any component within the data security management system100 can generate the initial request 244 to share the personal data 210from the client 201 to any other component within system 100, including,but not limited to the authenticator 208. In some other embodiments, theinitial request 244 to share personal data 210 to the authenticator 208from the client 201 can be generated by the client 201.

With reference to FIG. 10, the initial request 244 to share personaldata 210 is represented by at least one sharing request ledgertransaction 213 of the ledger 207. In some embodiments, the initialsharing request ledger transaction 213 can be generated within one ormany ledgers (not shown), different from the ledger 207. In someembodiments, the initial request 244 can be performed off the ledger 207using conventional data transfer protocols (e.g., HTTP, HTTPS, etc.). Inanother embodiment, the data security management system 100 comprises acombination of the ledger 207 transaction(s) and conventional datatransfer protocols to perform a request to share personal data 210 fromclient 201.

The sharing request ledger transaction 213 can be made to a randomrecipient address in order to protect client and authenticator privacy.In a preferred embodiment, contents of the request 244 can be encodedusing a public key 241 (of the authenticator 208 known by the client201), or the public key 202 (of the client 201 known by theauthenticator 208), or any other strong cipher. Advantageously, thisprotects both the request 244 and the response (the encoded personaldata 234) from being read by any third party. In some other embodiments,the request 244 can be partially subjected to cryptographic primitivesor not subjected at all.

A data sharing response (e.g., the encoded personal data 234) from theclient 201 to the authenticator 208 is represented by a ledgertransaction 214 that includes encoded personal data 234. In someembodiments, sharing response ledger transaction 214 can be generatedwithin one or many ledgers (not shown), different from ledger 207. Insome other embodiments, the sharing response 215 can be performed offthe ledger 207 using only conventional data transfer protocols (e.g.,HTTP, HTTPS, etc.). In another embodiment, the data security managementsystem 100 uses a combination of the ledger 207 transaction(s) andconventional data transfer protocols to perform a response with sharedpersonal data 210 from client 201.

The sharing response ledger transaction 214 can be made to the randomrecipient address in order to protect client and authenticator privacy.In some embodiments, a sharing response ledger transaction 214 can bemade to the smart contract 211 directly as shown in FIG. 11. Thecontents of response 215 represented by the ledger transaction 214 canbe encoded using the public key 241 of the authenticator 208, or anyother strong cipher.

In some embodiments, a sharing request 212 can be combined with sharingresponse 215 within a single data transfer session or ledger 207transaction. In a preferred embodiment, the authentication processdescribed above can be performed for the client 201 before, after, orsimultaneously with data transfer. For example, the authenticationprocess can be a part of the personal data 201 sharing process. In someembodiments, the authentication process can be replaced with a datasharing process because only having an access and being in control of IDsmart contract 205 and/or controller smart contract 206, the client 201can perform a valid sharing ledger transactions.

In some embodiments, the personal data 210 can never leave the client201. Instead of sharing data in any form, the client 201 can generate azero-knowledge proof of data existence and knowledge of the personaldata 210 without exposure of the personal data 210. In some otherembodiments, instead of sharing the personal data 210 from the client201, the authenticator 208 can instruct the client 201 to generate averifiable computational result on the client 201 without revealing thedata 210 contents. Stated in another way, a private contracts approach,such as the Enigma project/protocol from Enigma, can provide asecond-layer, decentralized computational protocol with both guaranteedprivacy of data and method for verifiable results.

In a preferred embodiment, each component of the data securitymanagement system 100, including the authenticator 208 and a verificator217 (shown in FIG. 12), can generate a verification 216 of the personaldata 210 for the client 201 as shown on FIG. 12. Turning to FIG. 12, theverification 216 can represent a proof of ownership and/or proof ofauthenticity of a personal data 210. In a preferred embodiment, theverificator 217 can produce the cryptographic data 218 using thepersonal data 210 and a cryptographic function 245. The cryptographicfunction 245 can include cryptographic primitives such as a one-way hashfunction and encryption function. In fact, although shown and describedas cryptographic data, the cryptographic data 218 can be partiallysubjected to cryptographic primitives or not subjected at all. However,the preferred embodiment comprises hashing the personal data 210 toproduce cryptographic data 218.

The cryptographic function 245 can include cryptographic primitives suchas a one-way hash function and encryption function, such as, forexample, a secure hash algorithm SHA-2, SHA-3, or any other reliablecryptographically strong hash function or combination thereof. As shownin FIG. 12, verification 216 includes at least cryptographic data 218,the client identifier 237 within the data security management system 100and a digital signature 219 made by verificator 217 for thecryptographical data 218 and the client identifier 237 using averificator private key 247 and a cryptographic function 246. Thecryptographic function 246 includes cryptographic primitives such as aone-way hash function and encryption function. In some embodiments, theverification 216 can include any other useful data and metadata, such asa timestamp. In another embodiment, a signature 219 can be made usingthe cryptographic data 218, the client identifier 237, and theverificator private key 247. The signature 219 also can comprise anyother useful data and/or metadata, such as a timestamp. In a preferredembodiment, each component within system 100 can perform an independentcheck of verification 216 by validating a digital signature 219, such asillustrated on FIG. 15.

In some embodiments, the verification 216 can be stored within storage(not shown). The data security management system 100 is suitable for usewith any type of storage, such as a decentralized distributed storage,for example, a distributed hash table, a distributed database, apeer-to-peer hypermedia distributed storage (e.g., InterPlanetary FileSystem (IPFS)), a distributed ledger (e.g., Blockchain), an operatingmemory, a centralized database, a cloud-based storage, and/or the like.In other embodiments, the storage is not decentralized or comprises acombination of distributed, decentralized servers, and centralizedservers. In even further embodiments, the storage can be maintained inoperating memory of any component in the data security management system100. The process of creating, storing, and maintaining consistency ofdata verifications described herein is also described incommonly-assigned, co-pending application Ser. No. 15/480,313, entitled“Method and System for Managing Personal Information Within IndependentComputer Systems and Digital Networks,” the disclosure of which ishereby incorporated by reference in its entirety.

In some other embodiments, a verification 216 can be stored withinledger 207 as a transaction or within the ledger 207 smart contractfields. In some embodiments, the storage could be the same as the ledger207. In some embodiments, the storage can be the same as the ledger 207.In some other embodiments, the verification 216 can be stored within theledger ID smart contract 205, ledger controller smart contract 206,and/or ledger smart contract 211. In other embodiments, the verification216 can be stored within the client 201, verificator 218, and/orauthenticator 208. In another embodiment, the verification 216 can bestored outside of the data security management system 100 or disposedafter processing to avoid any chance of theft. In yet another oneembodiment, the verification 216 can be hashed, encoded, and/or cipheredfor additional privacy.

Turning to FIG. 13, the data security management system 100 encodes theverification 216 onto the ledger 207. In other embodiments, theverification 216 can be encoded onto a ledger (not shown), differentfrom the ledger 207. In some embodiments, the data management securitysystem 100 provides the safety and integrity for multiple amounts ofverifications 216 within the data security management system 100, allwithin the parameters of a single ledger transaction on the ledger 207.By way of example, novel systems for storing data in a decentralizedmanner, while simultaneously having data integrity and consistency aredisclosed in commonly assigned, co-pending U.S. application Ser. No.15/480,313, filed Apr. 5, 2017, which application is hereby incorporatedby reference in its entirety and for all purposes. In some embodiments,each transaction corresponds to a single verification 216. Inalternative embodiments, each transaction represents a set ofverifications 216.

In a preferred embodiment, each new verification 216 generates a ledgertransaction 221 into the ledger 207 as shown on FIG. 14. Verificator 217can produce the cryptographic data 247 using verification 216 andcryptographic function 248, such as cryptographic primitives including,but not limited to one-way hash functions and encryption functions. Theverificator 217 can then generate a ledger transaction 221 within ledger207 containing cryptographic data 247. In some embodiments, the datasecurity management system 100 can secure several independentverifications 216 within a single ledger transaction 221, within theledger 207. In some embodiments, the ledger transaction 221 can be sentto a random address for better privacy as shown on FIG. 14. In someembodiments, the ledger transaction 221 can be made using client 201 IDsmart contract 205 and/or controller smart contract 206 direct addresses(e.g., ledger contract id).

In a preferred embodiment, any personal data 210 being shared fromclient 201 to any other component within the data security managementsystem 100 can be independently checked for verifications 216 made forclient 201 for the personal data 210 as shown in FIG. 15. A need tocheck for existence and validate verifications made for the personaldata 210 of the client 201 includes generation of the cryptographic data218 using the personal data 210 and a cryptographic function 245. Asillustrated on FIG. 15, the cryptographic data 218 can be coupled withthe client identifier 237 and the signature 219 to produce thecryptographic data 247 using cryptographic function 248, such ascryptographic primitives including, but not limited to one-way hashfunctions and encryption functions. The combination of the personal data210, client ID, and signature used to generate the cryptographic data247 can be checked (via independent generation of cryptographic data247) and compared to the cryptographic data 247 stored within the ledger207 transaction 221 to establish data validity and verificationauthenticity.

In some embodiments, the data security management system 100 can be usedwith systems for determining the level of trust that is required toengage in a transaction through a dynamic client-side scoring function.Judgment about whether to refer to specific data with confidence alwaysdepends on the internal business processes of the organization, thelevel of certification (compliance), and the requirements oflegislation. For example, while sufficient to verify age when purchasingalcohol, conventional methods of age verification are not appropriatefor the commercial bank when opening an account. Accordingly, novelsystems for determining the level of trust that is required to engage ina transaction are disclosed in commonly assigned, co-pending U.S.application Ser. No. 15/480,313, filed Apr. 5, 2017, which applicationis hereby incorporated by reference in its entirety and for allpurposes.

The data security management system 100 exponentially improvestrust-based decision making by allowing information sharing, withoutrunning afoul of data privacy laws that significantly restrict datacollection, use, and sharing activities. Among other ways, the datasecurity management system 100 enables transmission (inbound andoutbound) of identity flags that can be used to improve riskassessment—in the case of airlines for any would-be passenger in advanceof them reaching the airport, regardless of whether they have flown withyour airline before or not.

The solution overcomes the traditional challenges of using blockchaintechnology, demonstrated by recent events that have exposed problemsrelated to bandwidth reduction, hard forks and loss of customers bytaking a blockchain agnostic approach. Through aggregation and crosschecking, the use of multiple blockchains addresses the generalchallenge that blockchain could, by itself, constitute a single point offailure, and the more specific challenge of private blockchains, whichare often characterized by lower security levels.

It addresses the principal security challenge by depersonalizing datastored to the blockchain through a special shuffle and dice algorithm.The resulting mathematical representation of the actual data, if stolen,would be veritably useless. Yet, it still enables completeness andadequacy necessary for making trust-based decisions. This obfuscateddata stored in the blockchain obviates the need of higher security toprotect any underlying sensitive/personal data, and the risk ofbackdoors.

A blockchain-agnostic approach can decentralize the data securitymanagement system 100, avoid a single-point-of-failure problem, andcreate a trusted identity management system with obfuscated data thatcan be independently validated.

The advantages of the data security management system 100 includemanaging and storing personally identifiable data:

without storing open and/or meaningful data in a centralized storageavailable to hack/steal, making hacking attempts unappealing,

without storing any personal data in any form anywhere except of client'devices, de-risking any central-storage of client data by a companywhich is currently used,

without storing and using passwords, which may have been provedineffective and insecure,

without any centralized databases/authorities/third parties which mustbe relied on while providing data consistency and integrity at the sametime.

Applications

The systems and methods disclosed herein may be used in many differentcontexts in which Identity verification or access management isrequired, such as applications for external uses, including:

Online services, including dating/professional service providers,whereby individuals interact in the digital as well as the physicalworld—with an emphasis on name and age verification, background checks.

Employment—verification of work permits and entrydocumentation/immigration, as well as associated background checks onindividual identity and their attributes.

Adult Entertainment—Age verification, payment verification, frauddetection.

Gambling—Age verification, payment verification, fraud detection,previous user history and associated credit checks.

Immigration and cross-border movement of individuals—identity documentschecks, background checks and paperwork validity, citizenship andpermits to travel, validating claims of identity and identityattributes.

Fintech—digital banking security, transaction security, identity claimsfor financial fraud and access to funds or financial services, clearanceand compliance activity.

Debit/Credit Cards—Anti-money laundering (AML), fraud detection,transaction security, clearance verifications and card replacementauthentication.

Credit referencing and rating agencies—assurance of identity, fraud,previous behavior history, risk-based assessments.

National and International Travel—identity checks for country ofdestinations and their border authority, no fly lists, Interpol,politically exposed persons (PEP) lists, relevant law enforcement andgovernment authorities, border control agencies, airport infrastructure,security and customs.

Airline security, airline know your customer (KYC) processes, passengeridentification and risk assessment, inter-airline passenger behaviorhistory, flight manifest verification, passport and visa checks,passport verification, identity document verification, booking dataverification and accuracy checks (including online and mobile booking),fraud detection for payment, fraud detection for loyalty program claimsand abuses, identity claim verification, advanced passenger informationsystems (APIS) verification and passenger reputational scoring.

Data Entry—Correcting human error, automating correct entry process(e.g., Companies House data input (which is currently manual),International travel passenger data input, Credit referencing and ratingagencies—all of this is manual, subject to human error and potentiallack of attention to detail/quality staff training/impossibility ofcatching an error (for example, one as minute as a zero instead of theletter ‘O’).

Insurance—delayed flight insurance, credit card fraud insurance,mortgage insurance, payment default insurance. Risk assessment forinsurance premiums calculations, as well as trust score used for premiumpayouts and claims assessments.

Government Services—taxation, pensions, income declaration, revenue andcustoms assessments, tax evasion, etc.

National and International Individual Identity—documentation for carhire, real estate, medical services, and the need to verify both itsveracity and validity as well as assert ownership, or a transfer ofownership

Legal records—verifying the existence of and veracity of claimed legallyrecorded proceedings and documentation, verifying their source and theindividual to whom they pertain

Fraud protection—decentralized automated and client-controlledmonitoring for fraud activities and unusual patterns in identity use orbehavior, aggregate risk assessment, fraud detection and prevention.

The disclosed embodiments are susceptible to various modifications andalternative forms, and specific examples thereof have been shown by wayof example in the drawings and are herein described in detail. It shouldbe understood, however, that the disclosed embodiments are not to belimited to the particular forms or methods disclosed, but to thecontrary, the disclosed embodiments are to cover all modifications,equivalents, and alternatives.

1-20. (canceled)
 21. A method for data security management, comprising:generating a pair of cryptographic keys on a client device, the pair ofcryptographic keys comprising a public key and a private key; accessing,using the private key, an associated ledger identification smartcontract of a distributed ledger; providing an authentication requestfrom the client device to an authenticator, wherein the authenticatorcreates a ledger request transaction in the distributed ledger using anauthenticator smart contract of the distributed ledger; and producing,using the associated ledger identification smart contract, at least oneauthentication response ledger transaction in the distributed ledger,wherein the at least one authentication response ledger transactioncomprises a verification of possession of the private key by the clientdevice to the authenticator.
 22. The method of claim 21, wherein theledger identification smart contract is identified by a contractidentifier.
 23. The method of claim 21, wherein the authenticatorgenerates a random value, transmits the random value to the clientdevice, and produces authenticator cryptographic data using acryptographic function based on the generated random value.
 24. Themethod of claim 23, wherein producing the at least one authenticationresponse ledger transaction comprises producing client cryptographicdata at the client device using the cryptographic function and thetransmitted random value.
 25. The method of claim 21, wherein the ledgerrequest transaction comprises authenticator cryptographic data, andwherein the at least one authentication response ledger transactioncomprises client cryptographic data.
 26. The method of claim 21, furthercomprising: storing personal data on the client device, wherein theauthenticator generates a sharing request ledger transaction of thedistributed ledger; and providing a data sharing response from theclient to the authenticator by generating a sharing ledger transactionwithin the distributed ledger, wherein the personal data is verified forproof of ownership.
 27. The method of claim 21, wherein generating thepair of cryptographic keys comprises protecting the pair ofcryptographic keys with biometric data.
 28. The method of claim 21,wherein generating the pair of cryptographic keys comprises encryptingthe generated private key using a cryptographic primitive.
 29. Themethod of claim 21, wherein the distributed ledger comprises at leastone of an immutable distributed ledger, a public ledger, and a privateledger.
 30. A system for data security management, comprising: one ormore computer systems programmed to perform operations comprising:generating a pair of cryptographic keys on a client device, the pair ofcryptographic keys comprising a public key and a private key; accessing,using the private key, an associated ledger identification smartcontract of a distributed ledger; providing an authentication requestfrom the client device to an authenticator, wherein the authenticatorcreates a ledger request transaction in the distributed ledger using anauthenticator smart contract of the distributed ledger; and producing,using the associated ledger identification smart contract, at least oneauthentication response ledger transaction in the distributed ledger,wherein the at least one authentication response ledger transactioncomprises a verification of possession of the private key by the clientdevice to the authenticator.
 31. The system of claim 30, wherein theledger identification smart contract is identified by a contractidentifier.
 32. The system of claim 30, wherein the authenticatorgenerates a random value, transmits the random value to the clientdevice, and produces authenticator cryptographic data using acryptographic function based on the generated random value.
 33. Thesystem of claim 32, wherein producing the at least one authenticationresponse ledger transaction comprises producing client cryptographicdata at the client device using the cryptographic function and thetransmitted random value.
 34. The system of claim 30, wherein the ledgerrequest transaction comprises authenticator cryptographic data, andwherein the at least one authentication response ledger transactioncomprises client cryptographic data.
 35. The system of claim 30, theoperations further comprising: storing personal data on the clientdevice, wherein the authenticator generates a sharing request ledgertransaction of the distributed ledger; and providing a data sharingresponse from the client to the authenticator by generating a sharingledger transaction within the distributed ledger, wherein the personaldata is verified for proof of ownership.
 36. The system of claim 30,wherein generating the pair of cryptographic keys comprises protectingthe pair of cryptographic keys with biometric data.
 37. The system ofclaim 30, wherein generating the pair of cryptographic keys comprisesencrypting the generated private key using a cryptographic primitive.38. The system of claim 30, wherein the distributed ledger comprises atleast one of an immutable distributed ledger, a public ledger, and aprivate ledger.
 39. A non-transitory computer-readable medium havinginstructions stored thereon that, when executed by one or more computerprocessors, cause the one or more computer processors to performoperations comprising: generating a pair of cryptographic keys on aclient device, the pair of cryptographic keys comprising a public keyand a private key; accessing, using the private key, an associatedledger identification smart contract of a distributed ledger; providingan authentication request from the client device to an authenticator,wherein the authenticator creates a ledger request transaction in thedistributed ledger using an authenticator smart contract of thedistributed ledger; and producing, using the associated ledgeridentification smart contract, at least one authentication responseledger transaction in the distributed ledger, wherein the at least oneauthentication response ledger transaction comprises a verification ofpossession of the private key by the client device to the authenticator.